Self-directed access card issuance system

ABSTRACT

An access card issuance system comprising an access card issuance device located at a facility of an organization and a web server is disclosed. The access card issuance system provides a web interface in response to a request from a mobile device, and receives user information identifying a user of the mobile device. The system is also configured to validate the identity of an authorized individual associated with the facility identified by a user of the mobile device, and issue an access card to the user of the mobile device. The access card has indicia printed thereon identifying at least a portion of the user information, and programmable information encoded onto the access card providing access rights to the facility. The system further transmits, to the authorized individual, a message associated with issuance of the access card.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 16/381,616,filed Apr. 11, 2019, which claims the benefit of provisional applicationSer. No. 62/656,211, filed Apr. 11, 2018 and entitled “Self-DirectedAccess Card Issuance System,” which applications are incorporated hereinby reference in their entirety.

BACKGROUND

Many companies have chosen to require that visitors to companyfacilities are issued a “visitor badge” each time that visitor entersthe company's premises. Issuance of a badge generally requires a processin which a user provides information to a company representative,including their name, their host's name, and a signature indicating atime of arrival, as well as (possibly) a photograph that will beincluded on that visitor's badge. The company representative will thenuse a computer having specialized software installed thereon to formatthe visitor badge. The formatted visitor badge information is providedto a printing device, which in turn prints the visitor badge. Thevisitor badge is typically an access card having identifying informationfor the visitor printed thereon, as well as encoded information includedon the access card (e.g., in a programmable or fixed encoded chip) thatgrants the visitor access rights to at least a portion of a facility.

This arrangement has a number of drawbacks. For example, in manyinstances, companies may have facilities with unattended entrancepoints, and therefore may not have a company representative present toassist in creating a visitor badge. In these instances, the company mayplace a “self-service” visitor badge issuance station at the entrance;however, even in these circumstances, the company must include at theentrance a specially-configured computing system having software and/ordrivers installed thereon which are capable of capturing the requiredinformation and interfacing with a badge printer, a capturing and aprinting device, as well as software and/or drivers installed oncomputers to drive those devices. Depending on the software, a corporateemployee may be required to call/notify the host that a guest arrived.

SUMMARY

The present disclosure relates generally to methods and systems forself-directed access card issuance. In some instances, a visitor orfacility-authorized individual may be presented with a user interface atwhich user information can be captured. Upon validation of an authorizedindividual associated with the facility (e.g., a contact of the visitoror the facility-authorized individual themselves), an access card can beprinted.

In a first aspect, an access card printer includes a card printingsubsystem, a processing unit, and a memory communicatively connected tothe processing unit. The memory stores instructions executable by theprocessing unit including a card printing application wherein theinstructions, when executed, cause the access card printer to, inresponse to a request from a mobile device: provide a web interface tothe mobile device; receive, via the web interface, user informationidentifying a user of the mobile device, the user information includingan identity of an authorized individual associated with a facility;optionally validate the identity of the authorized individual associatedwith the facility; and issue an access card to the user of the mobiledevice, the access card having indicia printed thereon by the cardprinting subsystem identifying the user (e.g., an image of the user),and optionally, programmable information encoded onto the access cardproviding access rights to the facility. The device is furtherconfigured to transmit, to the authorized individual, a messageassociated with issuance of the access card.

In a second aspect, a method of issuing an access card at a facility isdisclosed. The method includes providing a web interface to a mobiledevice, and receiving, via the web interface, user informationidentifying a user of the mobile device, the user information includingan identity of an authorized individual associated with the facility.The method includes optionally validating the identity of the authorizedindividual associated with the facility, and issuing, at an access cardissuance device, an access card to the user of the mobile device,including printing indicia on the access card including at least aportion of the user information and, optionally, registering informationencoded onto the access card one or more access rights to the facilityfor the user. The method includes transmitting, from the access cardissuance device to the authorized individual, a message associated withissuance of the access card.

In a third aspect, an access card issuance system comprising an accesscard issuance device located at a facility of an organization and a webserver is disclosed. The access card issuance system is configured toprovide a web interface from the web server to a mobile device inresponse to a request from the mobile device, and receive, via the webinterface, user information identifying a user of the mobile device, theuser information including an identity of an authorized individualassociated with a facility. The system is further configured tooptionally validate the identity of the authorized individual associatedwith the facility, and issue an access card to the user of the mobiledevice from the access card issuance device, the access card havingindicia printed thereon identifying at least a portion of the userinformation, and, optionally, programmable information encoded onto theaccess card providing access rights to the facility. The system is alsoconfigured to transmit, to the authorized individual, a messageassociated with issuance of the access card.

A variety of additional aspects will be set forth in the descriptionthat follows. The aspects can relate to individual features and tocombinations of features. It is to be understood that both the foregoinggeneral description and the following detailed description are exemplaryand explanatory only and are not restrictive of the broad inventiveconcepts upon which the embodiments disclosed herein are based.

BRIEF DESCRIPTION OF THE DRAWINGS

The following drawings are illustrative of particular embodiments of thepresent disclosure and therefore do not limit the scope of the presentdisclosure. The drawings are not to scale and are intended for use inconjunction with the explanations in the following detailed description.Embodiments of the present disclosure will hereinafter be described inconjunction with the appended drawings, wherein like numerals denotelike elements.

FIG. 1 illustrates a network within which aspects of the presentdisclosure can be implemented, including an access card issuance deviceuseable according to an example embodiment;

FIG. 2 illustrates a network within which aspects of the presentdisclosure can be implemented, including an access card issuance deviceuseable according to a second example embodiment;

FIG. 3 illustrates an example computing device useable to implementaspects of the present disclosure;

FIG. 4 is a flowchart of a method for issuing a visitor access card at afacility via an access card issuance device, according to an exampleembodiment;

FIG. 5 is a flowchart of a method for capturing visitor information at amobile device, for use by an access card issuance device, according toan example embodiment;

FIG. 6 is a web interface useable by a visitor to provide userinformation to an access card issuance device, according to an exampleembodiment;

FIG. 7 illustrates the web interface of FIG. 6 including a hostidentification screen useable for capturing an identity of an authorizedindividual, according to an example embodiment;

FIG. 8 illustrates the web interface of FIG. 6 including a userinformation entry screen, according to an example embodiment;

FIG. 9 illustrates the web interface of FIG. 6 including an imagecapture screen, according to an example embodiment;

FIG. 10 illustrates the web interface of FIG. 6 including a signaturescreen, according to an example embodiment;

FIG. 11 illustrates the web interface of FIG. 6 including an access cardissuance screen, according to an example embodiment;

FIG. 12 illustrates a message transmitted to the authorized individualin conjunction with issuance of an access card to a visitor, accordingto an example embodiment;

FIG. 13 is a flowchart of a method of issuance of an access card to anauthorized individual, in accordance with an example embodiment of thepresent disclosures;

FIG. 14 is a web interface useable by an authorized individual toprovide user information to an access card issuance device, according toan example embodiment;

FIG. 15 illustrates a message transmitted to the authorized individualin conjunction with issuance of an access card to that authorizedindividual, according to an example embodiment;

FIG. 16 illustrates the web interface of FIG. 14 including a validationscreen, according to an example embodiment; and

FIG. 17 illustrates the web interface of FIG. 14 including an accesscard issuance screen, according to an example embodiment.

DETAILED DESCRIPTION

Various embodiments of the present invention will be described in detailwith reference to the drawings, wherein like reference numeralsrepresent like parts and assemblies throughout the several views.Reference to various embodiments does not limit the scope of theinvention, which is limited only by the scope of the claims attachedhereto. Additionally, any examples set forth in this specification arenot intended to be limiting and merely set forth some of the manypossible embodiments for the claimed invention.

As briefly described above, embodiments of the present invention aredirected to methods and systems for self-directed access card issuance.In some instances, a visitor or facility-authorized individual may bepresented with a user interface at which user information can becaptured. Upon validation of an authorized individual associated withthe facility (e.g., a contact of the visitor or the facility-authorizedindividual themselves), an access card can be printed. In otherinstances, an authorized user may, using his/her own mobile device,reissue themselves an access card in the event their existing accesscard is lost/stolen. In such instances, the authorized user can validatehim/herself prior to access card issuance.

In accordance with the various embodiments discussed below, it is notedthat the methods and systems described herein have a number ofadvantages over existing systems. For example, such systems are capableof generating visitor log entries automatically in association with cardissuance, and therefore reduce the need for trained security personnelto be present at facility entrances. Furthermore, because each cardissuance is tied to an authorized individual at that facility and thatauthorized individual can be automatically notified of the presence ofhis/her visitor, the need for trained security personnel is stillfurther reduced. Furthermore, because notifications to an authorizedindividual can include captured photographs of the visitor, theauthorized individual can visually verify that the visitor is thecorrect person prior to greeting the visitor. Additionally, because themethods and systems described herein (1) leverage the capabilities of amobile device of the user, and (2) are presented in a web interface,there is both a reduce need for expensive hardware (e.g., image and/orsignature capturing devices) at the facility entrance, or installationof specific application software on an uncontrolled (e.g., visitor's)mobile device. Since visitors may be one-time or rare visitors to afacility, those visitors may not wish to install rarely-usedapplications on their personal devices. Still further, because the badgeprinter either manages or is communicatively connected with a systemthat manages the web interface, the printer is not required tore-authenticate the visitor during that same visit, but prior toissuance of the visitor badge.

Referring now to FIG. 1, a network 10 is shown, within which aspects ofthe present disclosure can be implemented. The network 10 includes anaccess card issuance device, shown as printer 100. The printer 100 isgenerally configured to issue credentials, such as credential 150, tousers. The credential is typically generated by a printing softwarecomponent 104 of the printer 100, and typically includes printed indiciathereon. This information can include, for example, one or more of auser name, a picture, a signature, a duration of validity of the badge;an access level associated with the badge, a name of a host of the user,or other information associated with the user visit. The credential 150can typically also include an electronic chip, which can be authorizedat the time of printing to grant access rights to a facility to a holderof the credential 150. This could include programming access rights ontothe credential 150, or assigning a fixed identifier (e.g., code)included in the credential (e.g., an RFID code) with access rights in afacility database to allow the credential holder facility access.

In the embodiment shown, the printer 100 includes a web server 102included thereon. The web server 102 includes a badge template 106, animage rendering printing engine 108, and a web application 110, use andoperation of which are described below. Generally, the web server 102provides an interface between the printing software component 104 andone or more other devices, such as devices the printer 100 may becommunicatively connected to via either short-range wirelesscommunication or via a company network, or via the Internet, and alsoprovides user interfaces to remote systems that issue requests to theprinter 100.

In the embodiment shown, the printer 100 is communicatively connected toa web browser capable device 12, a host identity catalog 14, a mailserver 16, and optionally a host user 18, via network infrastructure 50(e.g., a corporate wireless network, public/cellular network, or somecombination thereof).

Typically, the web browser capable device 12 corresponds to a mobiledevice of a user. The user may be, for example, a visitor to a facility,or an authorized user at the facility seeking reissuance of a credential150. The web browser capable device 12 generally has a user interfaceincluding a web browser, as well as an image capture device (e.g., acamera). In typical scenarios, the web browser capable device is amobile touchscreen device having a camera and one or more of a 802.11(Wi-Fi) or cellular connection.

The host identity catalog 14 stores contact information and detailsregarding authorized individuals at the facility. The host identitycatalog can be, for example, a corporate directory, in the instance thefacility is associated with a corporation. However, in alternativeimplementations, the host identity catalog 14 can be any identityprovider, such as an authenticating website (e.g., Google, Facebook)which authenticates user identities, or other types of host identityrepositories (e.g., an organizational directory). For example, the hostidentity catalog 14 can include name, location, preferred contactinformation, and optionally second contact information of each of theauthorized individuals at the facility. Authorized individuals caninclude any individuals having authorization to access the facility, orauthorization to host visitors at the facility. Authorized individualscan include, for example, employees of a company operating the facility.In some embodiments in which the host identity catalog 14 comprises acorporate directory, the corporate directory can be implemented usingActive Directory software from Microsoft Corporation of Redmond,Washington. Other corporate directory software can be used as well.Generally, any LDAP/Active Directory arrangement would be suitable.

The mail server 16 manages communications with authorized individuals.For example, the mail server 16 can manage transmission of email, text,or automated voicemail messages to authorized individuals. In exampleembodiments, the mail server can correspond to a corporate mail server,for example implementing Microsoft Exchange Server software fromMicrosoft Corporation of Redmond, Washington. Other types of corporatemail servers or other mail server devices (e.g., cloud-based mailservers, etc.) can be used as well.

The host user 18 generally corresponds to a desktop or mobile deviceassociated with an authorized individual at the facility. Typically, asdiscussed in the use cases herein, the host user 18 represents acomputing device of an authorized individual identified by a visitorduring the methods for self-directed card issuance described herein.

Referring back to the printer 100, and the web server 102 specifically,the web server 102 can be implemented in memory of the printer 100, andwill store instructions useable to (1) interface with visitors andauthorized users, (2) form access cards (e.g., badges, represented bycredential 150) from captured information in a predetermined format, and(3) communicate with servers and devices within an organization tovalidate the visitor or authorized individual, to ensure thatcredentials 150 are only issued to those users who are expected orallowed to be present. To that end, the badge template 106 of the webserver 102 will store one or more badge templates, which includes aphysical layout of printed indicia to be included on the physicalcredential when issued. The badge template can include a set of requiredinformation (e.g., name, image of the user, optionally a visitor oremployee identification number) as well as information about how toassociate the credential 150 with access rights (e.g., specificprogramming to be included on the credential 150, or a method by which acode on the access card can be granted access by associating that codewith access rights in a security database (not shown)). An imagerendering and printing engine 108 can be included in the web server 102,and will receive image data captured by the web browser capable devicefrom the web application 110 for rendering in the printed indicia on thecredential, e.g., as defined in a particular badge template 106.

The web application 110 generates and provides a web interface includinga plurality of user screens that guide a user through self-issuance ofan access card (e.g., credential 150). The web application 110 isinstantiated at startup of the web server 102 (e.g., at startup of theprinter 100 in the example of FIG. 1). In the embodiment of FIG. 1, inaddition to all services requires to operate/print, the printer starts aweb server 102 as an application which makes available to any webclient-capable application (i.e., a Web Browser) a customizable webapplication 110, which is implemented, in some embodiments, as a set ofHTML pages and associated JavaScript. In some embodiments, the webapplication 110 is stored in memory of the printer; in alternativeembodiments, the web application 110 is downloaded, after the web server102 is started, from a predefined location that is known to the printer100. Notably, no other specific software applications are required oneither the printer 100 or on other devices, e.g., the web browsercapable device 12.

In the embodiment shown, the web application 110 can host the webinterface at a predetermined web address, e.g., within a company'sinter- or intra-net. In some embodiments, user devices that connect to acompany's wireless network at a facility can be redirected to a userscreen that allows the user to initiate the credential issuance process.In other embodiments, a user may be directed to navigate in a webbrowser to a particular website. In still other embodiments, a user mayobtain a uniform resource locator (URL) of the website by other means,such as by reading an NFC tag included at the printer 100, which canthen be used by a web browser of the web browser capable device 12 toaccess the website hosted by web application. In example embodiments,the web application can generate screens and guide a user through aprocess for self-directed issuance of an access card as are shown inFIGS. 4-16.

FIG. 2 illustrates a network 200 within which aspects of the presentdisclosure can be implemented, including an access card issuance deviceuseable according to a second example embodiment. The network 200generally corresponds to network 10 of FIG. 1; however, as illustrated,the web server 102 can be a device separate from the printer 100 andcommunicatively connected to the printer. As such, the web server 200need not necessarily be present at the facility, and need not beintegrated into the printer 100, thereby avoiding a requirement that theprinter 100 have substantial computing capabilities, and allowing theprinter 100 to be a lower-cost device.

Referring to FIGS. 1-2 generally, it is noted that operation of bothnetworks 200 can be analogous. Once the web interface presented by theweb application 110 is used by a user of the web browser capable device12 to capture user information, the web server 102 can provide thatinformation, in a format defined by the badge template 106, to aprinting software component 104, which can issue a credential 150. It isnoted that the credential can be a credential for a visitor user, oroptionally, a reissued credential for an authorized individual at thefacility (e.g., in the case of a lost or stolen credential). In somecases (e.g., at least in the cases of visitor credential issuance) oncethe credential is issued, at least a portion of the user information canbe stored in a visitor log 120. This can include, for example, the username of the visiting user, the name of an authorized individual, orhost, of the visiting user, an image of the visiting user, a signatureof the visiting user captured at the web browser capable device 12, anda timestamp associated with issuance of the credential. It is noted thatin example embodiments, the visitor log 120 can store user name andother logged information in an encrypted format to preserve security.

Furthermore, during the credential issuance process, the web server 102can initiate communication with an authorized individual. This can occurin a number of circumstances. In the case of a visiting user, theauthorized individual can represent a host of that visiting user, andtherefore the web server 102 will, based on contact information of theauthorized individual registered in the host identity catalog 14,initiate communication with the authorized individual, either via mailserver 16 or directly to host user 18. This communication can be, forexample, an email, text message, or automated voice message indicatingto the authorized individual that his/her visitor has arrived, andoptionally, that the visiting user has completed the access cardissuance process. In cases where an email or text message is provided,the message can include an image of the visiting user, so the authorizedindividual can readily identify the visiting user as the correct person.Furthermore, the message can be provided to the authorized individualeither before or after the credential 150 is actually issued by theprinter.

Alternatively, in cases where the user is also the authorized user(e.g., in the case of credential reissuance), the message to theauthorized user can be used for two-factor authentication of that userprior to issuance. For example, the message can be a text messageincluding an authorization code that may be a required entry in the webinterface for validation that the user of the web browser capable device12 is in fact the authorized user, e.g., by sending the authorizationcode to the phone number of the authorized user listed in the hostidentity catalog 14.

Still referring to FIGS. 1-2 generally, it is noted that a number ofcomponents of networks 10, 200 may be at locations other than at theparticular facility for which access is sought. For example, generally,the printer 100 and the web browser capable device 12 will be at thefacility, since the user seeking a credential 150 will have possessionof the web browser capable device 12, and the printer 100 will bepresent in order to issue the credential. Additionally, preferably(assuming the authorize user is also present at the facility), the hostuser device 18 may also be at the facility. However, the host identitycatalog 14 and mail server 16 may be at some other facility managed bythe company associated with the facility, and in some instances (such asin the embodiment of FIG. 2), the web server 102 may also be remote fromthe facility. Still other possible configurations of components areapparent from the discussion above and are contemplated by the presentdisclosure.

Referring now to FIG. 3, a computing device 300 is shown, with whichaspects of the present disclosure can be implemented. The computingdevice 300 can be used, for example, to implement a printer 100, webserver 102, or any of devices 12-18 as described above in connectionwith FIGS. 1-2.

In the example of FIG. 3, the computing device 300 includes a memory302, a processing system 304, a secondary storage device 306, a networkinterface card 308, a video interface 310, a display unit 312, anexternal component interface 314, and a communication medium 316. Thememory 302 includes one or more computer storage media capable ofstoring data and/or instructions. In different embodiments, the memory302 is implemented in different ways. For example, the memory 302 can beimplemented using various types of computer storage media, and generallyincludes at least some tangible media. In some embodiments, the memory302 is implemented using entirely non-transitory media.

The processing system 304 includes one or more processing units, orprogrammable circuits. A processing unit is a physical device or articleof manufacture comprising one or more integrated circuits thatselectively execute software instructions. In various embodiments, theprocessing system 304 is implemented in various ways. For example, theprocessing system 304 can be implemented as one or more physical orlogical processing cores. In another example, the processing system 304can include one or more separate microprocessors. In yet another exampleembodiment, the processing system 304 can include anapplication-specific integrated circuit (ASIC) that provides specificfunctionality. In yet another example, the processing system 304provides specific functionality by using an ASIC and by executingcomputer-executable instructions.

The secondary storage device 306 includes one or more computer storagemedia. The secondary storage device 306 stores data and softwareinstructions not directly accessible by the processing system 304. Inother words, the processing system 304 performs an I/O operation toretrieve data and/or software instructions from the secondary storagedevice 306. In various embodiments, the secondary storage device 306includes various types of computer storage media. For example, thesecondary storage device 306 can include one or more magnetic disks,magnetic tape drives, optical discs, solid-state memory devices, and/orother types of tangible computer storage media.

The network interface card 308 enables the computing device 300 to senddata to and receive data from a communication network. In differentembodiments, the network interface card 308 is implemented in differentways. For example, the network interface card 308 can be implemented asan Ethernet interface, a token-ring network interface, a fiber opticnetwork interface, a wireless network interface (e.g., WiFi, WiMax,etc.), or another type of network interface.

The video interface 310 enables the computing device 300 to output videoinformation to the display unit 312. The display unit 312 can be varioustypes of devices for displaying video information, such as an LCDdisplay panel, a plasma screen display panel, a touch-sensitive displaypanel, an LED screen, a cathode-ray tube display, or a projector. Thevideo interface 310 can communicate with the display unit 312 in variousways, such as via a Universal Serial Bus (USB) connector, a VGAconnector, a digital visual interface (DVI) connector, an S-Videoconnector, a High-Definition Multimedia Interface (HDMI) interface, or aDisplayPort connector.

The external component interface 314 enables the computing device 300 tocommunicate with external devices. For example, the external componentinterface 314 can be a USB interface, a FireWire interface, a serialport interface, a parallel port interface, a PS/2 interface, and/oranother type of interface that enables the computing device 300 tocommunicate with external devices. In various embodiments, the externalcomponent interface 314 enables the computing device 300 to communicatewith various external components, such as external storage devices,input devices, speakers, modems, media player docks, other computingdevices, scanners, digital cameras, and fingerprint readers.

The communication medium 316 facilitates communication among thehardware components of the computing device 300. The communicationsmedium 316 facilitates communication among the memory 302, theprocessing system 304, the secondary storage device 306, the networkinterface card 308, the video interface 310, and the external componentinterface 314. The communications medium 316 can be implemented invarious ways. For example, the communications medium 316 can include aPCI bus, a PCI Express bus, an accelerated graphics port (AGP) bus, aserial Advanced Technology Attachment (ATA) interconnect, a parallel ATAinterconnect, a Fiber Channel interconnect, a USB bus, a Small Computingsystem Interface (SCSI) interface, or another type of communicationsmedium.

The memory 302 stores various types of data and/or softwareinstructions. The memory 302 stores a Basic Input/Output System (BIOS)318 and an operating system 320. The BIOS 318 includes a set ofcomputer-executable instructions that, when executed by the processingsystem 304, cause the computing device 300 to boot up. The operatingsystem 320 includes a set of computer-executable instructions that, whenexecuted by the processing system 304, cause the computing device 300 toprovide an operating system that coordinates the activities and sharingof resources of the computing device 300. Furthermore, the memory 302stores application software 322. The application software 322 includescomputer-executable instructions, that when executed by the processingsystem 304, cause the computing device 300 to provide one or moreapplications. The memory 302 also stores program data 324. The programdata 324 is data used by programs that execute on the computing device300.

Although particular features are discussed herein as included within anelectronic computing device 300, it is recognized that in certainembodiments not all such components or features may be included within acomputing device executing according to the methods and systems of thepresent disclosure. Furthermore, different types of hardware and/orsoftware systems could be incorporated into such an electronic computingdevice.

For example, if printer 100 is implemented, an additional card printingsubsystem may be included in such a device 300, for issuance ofcredentials 150, as well as the software discussed above in connectionwith FIGS. 1-2. Additionally, in the case of the web browser capabledevice 12, certain application software (e.g., a web browser) andhardware devices (e.g., a touch-screen user interface, optionally awireless identification chip such as an NFC or RFID reader) may beincluded as well.

In accordance with the present disclosure, the term computer readablemedia as used herein may include computer storage media andcommunication media. As used in this document, a computer storage mediumis a device or article of manufacture that stores data and/orcomputer-executable instructions. Computer storage media may includevolatile and nonvolatile, removable and non-removable devices orarticles of manufacture implemented in any method or technology forstorage of information, such as computer readable instructions, datastructures, program modules, or other data. By way of example, and notlimitation, computer storage media may include dynamic random accessmemory (DRAM), double data rate synchronous dynamic random access memory(DDR SDRAM), reduced latency DRAM, DDR2 SDRAM, DDR3 SDRAM, solid statememory, read-only memory (ROM), electrically-erasable programmable ROM,optical discs (e.g., CD-ROMs, DVDs, etc.), magnetic disks (e.g., harddisks, floppy disks, etc.), magnetic tapes, and other types of devicesand/or articles of manufacture that store data. Communication media maybe embodied by computer readable instructions, data structures, programmodules, or other data in a modulated data signal, such as a carrierwave or other transport mechanism, and includes any information deliverymedia. The term “modulated data signal” may describe a signal that hasone or more characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media may include wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, radiofrequency (RF), infrared, and other wireless media.

It is noted that, in some embodiments of the computing device 300 ofFIG. 3, the computer-readable instructions are stored on devices thatinclude non-transitory media. In particular embodiments, thecomputer-readable instructions are stored on entirely non-transitorymedia.

Referring now to FIGS. 4-5, flowcharts of methods for issuing a visitoraccess card at a facility are shown. FIG. 4 illustrates a method capableof being performed by a printer and/or web server, such as the printer100 and web server 102 of FIGS. 1-2. FIG. 5 illustrates a method capableof being performed at the web browser capable device 12, based onscreens generated and provided to such a device by the web server 102,and particularly the web application 110.

Referring specifically to FIG. 4, the method 400 is initiated by the webbrowser enabled device, once that device is directed to an appropriateweb address for screens hosted by the web server 102. The web server 102receives a host name from the web application 110 (which collects thatinformation via screens discussed below in connection with FIGS. 6-11)(step 402). The web server performs a lookup in a host identity catalog,such as host identity catalog 14 of FIGS. 1-2 (step 404).

In the embodiment shown, a determination is made as to whether theauthorized user identified by the host name exists in the host identitycatalog, such as a corporate directory (at operation 406). If the hostdoes not exist, optionally, the user is allowed to retry entry of a hostname (not shown); however, if the user is unable to provide a correcthost name that corresponds to an authorized user in the host identitycatalog, operation branches “no” and a message is sent to a help desk ofthe facility. The help desk of the facility may be an offsite desk thatcan call the user to assist with identifying an authorized user, whilenot requiring help desk personnel to be at the facility.

If the user provides a name of an authorized user that exists in thehost identity catalog, operation branches “yes”, and proceeds withcapturing user information from the visiting user (step 408).Specifically, the web server will provide a plurality of userinformation screens, in response to which a user at the web browsercapable device 12 can provide such user information. As illustrated inthe screens of FIGS. 6-11, the user information can include, forexample, a visiting user's name, a photograph of the visiting user(e.g., as captured at the web browser capable device 12, and a signatureof the visiting user.

In the embodiment shown, a preview of the visitor's access card will begenerated and provided via a web interface (step 410), for example,based on the information received from the user and generated accordingto a badge template 106, as in FIGS. 1-2.

Additionally, printer 100 can then issue the credential 150 (e.g., byprinting and, if necessary, programming the badge) (step 412), andtransmitting a message to the authorized individual identified by hostname (step 414). As seen in FIG. 12 below, the message to the authorizedindividual can include a name, time, and image of the visitor user forreview/approval by the authorized individual. Furthermore, at the timeof badge issuance, the visitor can be logged, e.g., in visitor log 120(step 416).

Referring to FIG. 4 generally, it is noted that certain steps may bereordered in various embodiments. For example, a visitor log entry maybe made in the case of any attempted access of the facility, and in suchcases, the log entry need not be made after issuance of a credential(e.g., prior to step 412). Furthermore, in some cases, no preview of thebadge may be provided at all (at step 410). Still further, the visitor'suser information may be captured prior to determining whether anauthorized individual exists in the corporate directory; such anarrangement may assist a help desk in identifying the visitor (or assistthe help desk in locating an authorized user associated with thevisitor) by including the visitor's user information in the message tothe help desk. In still further examples, the host could be sent amessage at the time the web server 102 receives a host name (steps402-404), rather than waiting for completion of issuance of the visitorbadge.

Additionally, it is noted that the method of FIG. 4 can be initiated ina number of ways. Typically, the method 400 can be initiated by a webbrowser capable device 12 visiting a URL hosted by the web server 102that presents a user interface for self-directed access card issuance.Visiting the URL results in the web browser capable device 12 issuing arequest to the web browser for the user interface as described herein.The URL can be obtained at the web browser enabled device by, forexample: the web browser capable device 12 joining a local wirelessnetwork and being redirected to the URL, a user typing in the URL (e.g.,based on a sign posted at the facility), or by receipt of the URL via ashort-range wireless communication protocol (e.g., via Bluetooth, NFC,or RFID connection to a memory associated with the printer 100 andstoring the URL) or other visual capture means (e.g., via QR code).

FIG. 5 is a flowchart of a method 500 for capturing visitor informationat a mobile device, for use by an access card issuance device, accordingto an example embodiment. The method 500 is generally performed at theweb browser capable device 12 of FIGS. 1-2.

In the example embodiment shown, the method 500 includes displaying auser interface (step 502) at the web browser capable device 12, forreceiving user information from a visitor user. In example embodiments,the user interface will be displayed in response to an HTTP GET requestusing the URL that is obtained and entered in a web browser that ispreinstalled on the web browser capable device 12. As noted above,displaying the user interface can be performed in response to variousways in which the web browser capable device 12 may receive the URL ofthe user interface. Example user interface screens included in the userinterface are provided below in conjunction with FIGS. 6-11. One initialscreen 600 for the user interface is presented in FIG. 6; in thatexample, a welcome screen 600 is presented that includes a continueoption 602, an employee credential reissuance option 604, and a cardpreview region. Additionally, navigation guidance, in the form of ahighlighted sequence of screens (e.g., “start”, “contact”,“information”, “picture”, “signature”, and “print”) are provided toguide a user through a self-directed card issuance process, each ofwhich represents different screens as discussed below.

The method 500 includes receiving, at a user interface, a host name ofan authorized individual acting as a host of the visiting user, andtransmitting the host name to the web server 102 (step 504). This can beperformed using a host identification screen 700 of FIG. 7, which can bereached by selecting continue option 602 on screen 600 of FIG. 6. Asseen in FIG. 7, a user lookup field 702 can be provided that allows auser to type a name of an authorized individual. In this case, anauthorized individual “John Doe” is sought, and appears among a set ofsearch results 703 that are obtained via querying a host identitycatalog, such as is seen in FIGS. 1-2.

It is noted that in FIG. 7, because the continue option 602 wasselected, the card preview region 606 begins to be populated with cardinformation, including a “visitor” designation”, as well as a date, anda badge number (e.g., assigned based on a next available badge number).This layout of the card can be based on the card template 106 of FIGS.1-2.

Continuing with FIG. 5, the method 500 includes receiving, at the userinterface, a visitor name of the visiting user at the web browsercapable device 12, and transmitting the visitor name to the web server102 (step 506). This can be performed using a user information entryscreen 800, such as is seen in FIG. 8. The user information entry screencan be reached by selecting the continue option 704 of screen 700 ofFIG. 7. As illustrated in that screen, name entry fields 802, 804 areprovided. As a user enters his or her name (in the example shown, “JoeBadge”), the name information populates into the card preview region 606as well, alongside information previously included. Additionally, if theuser wishes to start over or go back to a previous user informationentry step, a previous screen option 805 is presented.

Continuing with FIG. 5, the method 500 also includes receiving, at theuser interface, a photograph of the visiting user, and transmitting thephotograph to the web server 102 (step 508). This can be performed usingan image capture screen 900 of the user interface, as seen in FIG. 9,which can be reached using the continue option 806 of the userinformation entry screen 800. The image capture screen includes an imagecapture region 902 which can be selected (e.g., via touch) by a user,which allows the user to take a photograph of him/herself using either afront- or rear-facing camera of the web browser capable device 12. Thephotograph can be presented in the card preview region 606. To retakethe photograph, or return to previous steps, a previous screen option905 is presented.

Continuing with FIG. 5, the method 500 also includes receiving, at theuser interface, a signature of the visiting user, and transmitting thesignature to the web server 102 (step 510). This can be performed usinga signature screen 1000 of FIG. 10, in an example embodiment. Thesignature screen 1000 includes a signature region 1002 in which a usersignature can be captured (signed with the visiting user's finger). Aprevious screen option 1005 allows the user to return to the imagecapture screen 900, while a reset signature option 1007 allows the userto reset the signature and re-sign. It is noted that in the embodimentshown, the signature captured in the signature region 1002 is notincluded in the card preview region 606, for example based on thesignature not being among information to be included on a visitor accesscard in the card template 106 of FIGS. 1-2. However, in otherembodiments, the signature could be included, or may be included on areverse side of the card (not shown). Generally, although various typesof user information can be collected using the user interfaces describedherein, all or only some of that information may be printed on theaccess card (e.g., credential 150) or logged in the visitor log 120, invarious embodiments. The types of information included on the accesscard is defined by the card template 106.

Continuing with FIG. 5, the method 500 also includes receiving, at theuser interface, a print confirmation from the visiting user, andtransmitting a print instruction to the web server 102 (step 512). Thiscan be accomplished using a print confirmation screen 1100 of FIG. 11,which can be reached via the continue option 1006 of the signaturescreen 1000 of FIG. 10. The print confirmation screen 1100 presents, inthe card preview region 606, the access card (e.g., credential 150) asit would be issued by the access card issuance device (e.g., printer100). For example, upon selection of a print option 1102, the web server102 in turn formulates card data based on the card template 106 and atleast a portion of the user information captured via steps 506-510, andtransmits that card data to the printing software component 104 of theprinter 100 for issuing credential 150.

Referring back to FIG. 4, and with reference to FIG. 12, it is notedthat, in association with printing the credential 150 at the printer100, a message can be transmitted to the authorized individual (e.g.,host) that the visiting user has arrived at the facility. This can occurbefore, during, or after printing of the credential, and can be based oncontact information of the authorized individual as recorded in thecorporate directory. One example of such a message is illustrated inFIG. 12, which is a schematic illustration of a user interface 200 of ahost device 18. The schematic illustration shows a communication 1202that can be sent to a host device 18, e.g., via mail server 16. In theexample shown, a text message from an automated system (e.g.,visitor.front.desk@domain.com) is received and includes a name of thevisiting user, a photograph of the visiting user, and a specific time atwhich the message is sent. As such, an authorized user, acting as a hostof the visiting user, can meet the visiting user at the facilityentrance, or other predetermined location. Although a text message isillustrated, various other types of automated communications may be usedas well. For example, an email could be sent including similar userinformation of the visiting user, or an automated voice message. In thecase of an automated voice message, since a photograph cannot readily betransmitted to allow the authorized individual to validate the user,optionally, other user information could be captured (e.g., a shortvoice message recorded at the web browser capable device 12) that wouldbe able to be captured and played back to the authorized individual forvalidation. Still other possibilities exist as well, consistent with thepresent disclosure.

Referring to FIGS. 4-5 generally, it is noted that the steps describedin both Figures are largely able to be performed in any order, otherthan that the print instruction is typically executed only afteradequate user information is received, and preferably performed aftervalidation that a host name corresponds to an authorized individual(host) at the facility. However, the order in which various informationis collected from a visitor user is largely arbitrary.

Referring now to FIGS. 13-17, a further use case of embodiments of thepresent disclosure is described, specifically for use in conjunctionwith reissuance of an access card (e.g., credential 150) for anauthorized individual. FIG. 13 is a flowchart of a method 1300 ofissuance of an access card to an authorized individual, in accordancewith an example embodiment. The method 1300 includes providing a userinterface (step 1302), which can include providing the user interfacepreviously described, e.g., in FIG. 6. However, in conjunction withsubsequent steps of FIG. 13, screens and messages generated by the webserver can be generated in response to selection of the employee reissueoption 604 of FIG. 6 at the web browser capable device 12.

In the embodiment shown, the method 1300 includes receiving, at the userinterface, a username and credentials of the authorized individual, andtransmitting the username and credentials to the web server 102 (step1304). This can be accomplished by receiving username and credential(e.g., password) information associated with an authorized user in auser information entry screen 1400, such as that shown in FIG. 14. Asseen in the user information entry screen 1400, username region 1402 andpassword region 1404 are included, as well as card preview region 1406.Since the user has not yet been validated, the card preview region 1406remains generic, and may include some basic template elements as definedby the card template 106 (e.g., such as a location of an image of theauthorized user and badge number, as shown). A continue option 1410allows the authorized user to submit the username and passwordinformation entered in regions 1402, 1404, while a previous option 1408returns the user to the welcome user interface 600 of FIG. 6.

In the embodiment shown, the method 1300 includes performing, at the webserver 102, a lookup of the authorized user based on the username andcredentials received at the web browser capable device 12 (step 1306).The lookup can occur in the host identity catalog 14, to validate thatthe user and credentials are correct.

Assuming the correct information is entered, in the embodiment shown,the method 1300 includes sending, from the web server to the web browsercapable device 12 a two-factor authentication code for validation of theuser (step 1308). The two-factor authentication code can be sent fromthe web server 102 via the mail server 16 based on contact informationin the host identity catalog 14, e.g., via text message. The two-factorauthentication code can be, for example a six-digit number transmittedto the user, which is received at the web browser capable device 12(step 1310). An example of receipt of such an authentication code isillustrated in the message shown in FIG. 15. In that figure, a schematicview 1500 of a web browser capable device 12 receiving such anauthentication code by text message 1502 is illustrated. The text code(in this case “123456”) is provided to the user for entry into the userinterface, e.g., in the validation screen 1600 of FIG. 16. In thevalidation screen 1600, a validation region 1602 is provided forentering the validation code, to ensure that the authorized user is infact the user seeking to reissue his/her access card. The validationscreen 1600 is reached in response to the user entering a valid usernameand password, and therefore includes, in the card preview region 1406, arepresentation of the authorized individual's access card to be printed,including a previously-stored name, photograph, badge number andoptionally other user information that may be in the host identitycatalog 14.

Upon entry of the validation code and selection of a continue option1606 of the validation screen 1600 the web server 102 could validate theuser by matching the transmitted and received validation codes (step1312). Upon validating the user, the web server could present the userwith a badge issuance screen 1700 as seen in FIG. 17. Selection of thebadge issuance option 1702 would result in transmission of a badgereissue instruction from the web browser capable device 12 to the webserver 102 which would then be relayed to the printing softwarecomponent 104 of the printer 100 for issuance of a credential 150 (e.g.,a reissued access card). If any changes to the badge were required, theuser could select a previous option 1704 on the badge issuance screen1700 to return to prior screens as needed.

It is noted that if the correct username and password information is notentered in the screen 1400 of FIG. 14, the user will not receive a textmessage, since no such user would be found in the host identity catalog14. Accordingly, such a user could not enter a code in the validationscreen 1600 of FIG. 16, and therefore could not proceed successfully toreissue a credential 150. Such an unauthorized user could not proceedvia the continue option 1606 of FIG. 16, and would either select theprevious option 1604 to return to screen 1400 to log in as a differentuser, or would otherwise be prevented from proceeding. Optionally, aftera predetermined number of attempts (one or more) such access attemptscould be logged either in the visitor log 120 or communicated to aremote system administrator or security desk for attention.

Referring to FIG. 13 generally, it is noted that, as with FIGS. 4-5above, the various user information gathering processes may be performedin a different order consistent with the present disclosure.Furthermore, additional operations may be included as well, not depictedabove. For example, if an authorized individual is reissued a new accesscard, one or more operations may be performed to invalidate thatindividual's previous badge, to prevent access to the facility by anunauthorized possessor of that lost/stolen badge.

Referring to FIGS. 1-17 generally, and in particular to the access cardissuance devices and methods described herein, there are a number ofadvantages over existing systems apparent from the present disclosure.In particular, self-directed access card (e.g., credential) issuanceallows users to print access cards without requiring dedicated securitypersonnel at a facility, which may be particularly useful at remote orrarely-visited facilities. Still further, in such situations, visitorsdo not wish to install specialized software on personal mobile devices,and therefore the present disclosure provides a web-enabled method bywhich badges can be reissued by leveraging capabilities of typicalmobile devices (e.g., cameras and touch screens for signature capture)while avoiding a requirement of such specialized software.

Although the present disclosure has been described with reference toparticular means, materials and embodiments, from the foregoingdescription, one skilled in the art can easily ascertain the essentialcharacteristics of the present disclosure and various changes andmodifications may be made to adapt the various uses and characteristicswithout departing from the spirit and scope of the present invention asset forth in the following claims.

1-26. (canceled)
 27. An access card printer comprising: a card printingsubsystem; a processing unit; a memory communicatively connected to theprocessing unit, the memory storing instructions executable by theprocessing unit wherein the instructions, when executed, cause theaccess card printer to: provide a web application to a mobile device;receive, via the web application, login credentials from a user of themobile device; verify the login credentials as corresponding to anauthorized user; transmit a first code to a verified device associatedwith the authorized user; receive a second code, via the webapplication, from the mobile device; verify the second code by comparingthe second code to the first code; and based on verifying the secondcode, instruct the card printing subsystem to print an access card,wherein the access card includes access card information providingaccess rights to a facility, the access rights being associated with theauthorized user, and the access card information is printed on theaccess card.
 28. The access card printer of claim 27, wherein verifyingthe login credentials comprises: transmitting the login credentials toan identity catalog; and receiving authorized user information from theidentity catalog.
 29. The access card printer of claim 28, wherein: theidentity catalog comprises a database of one or more users authorized toaccess the facility, and the authorized user information comprises oneor more of an authorized user phone number, an authorized user e-mailaddress, an authorized user name, an authorized user picture, anauthorized user badge number, and an authorized user access level. 30.The access card printer of claim 29, wherein the identity catalog, inresponse to receiving the login credentials, matches the logincredentials with an entry in the database of one or more usersauthorized to access the facility; the authorized user informationcorresponds to the entry in the database of one or more users authorizedto access the facility; and the verified device corresponds with theauthorized user information.
 31. The access card printer of claim 27,wherein transmitting a first code to a verified device is performed bytransmitting the first code via a mail server.
 32. The access cardprinter of claim 27, wherein the verified device is the mobile device.33. The access card printer of claim 27, wherein the web applicationcomprises a plurality of web interface screens, the plurality of webinterface screens including a welcome screen, a user information entryscreen, a validation screen, and a badge issuance screen.
 34. The accesscard printer of claim 33, wherein: the memory further stores a badgetemplate; the validation screen displays the access card information inaccordance with the badge template; and the badge issuance screendisplays the access card information in accordance with the badgetemplate.
 35. The access card printer of claim 27, wherein the memoryfurther stores a log, and wherein the instructions further cause theaccess card printer to record, in the log, one or more of a time stampor the login credentials in response to the access card printerreceiving, via the web application, the login credentials.
 36. Theaccess card printer of claim 27, wherein providing the web applicationto the user of the mobile device is performed in response to a requestfrom the mobile device.
 37. The access card printer of claim 36, whereinthe request from the mobile device includes one or more of: the mobiledevice registering on a wireless network at the facility; the mobiledevice sending an HTTP GET request using a URL associated with theaccess card printer; or a request, via a mobile application on themobile device, wherein the mobile application is associated with theaccess card printer.
 38. The access card printer of claim 27, whereinthe second code is a same code as the first code, and comparing thesecond code to the first code includes determining that the second codematches the first code.
 39. The access card printer of claim 27, whereinthe memory further stores a badge template; and wherein instructing thecard printing subsystem to print the access card comprises instructingthe card printing subsystem to format, in accordance with the badgetemplate, the access card information on the access card.
 40. The accesscard printer of claim 39, wherein the badge template includes one ormore of a name space, a date space, a duration space, an access levelspace, an access code space, a badge number space, and a picture space.41. The access card printer of claim 27, wherein the instructions arefurther encoded to cause the access card printer to invalidate aprevious access card, the previous access card providing access rightsto the facility to the user of the mobile phone.
 42. The access cardprinter of claims 27, wherein the user of the mobile device is anemployee of the facility.
 43. A method of issuing an access card at afacility, the method comprising: providing a web application to a mobiledevice; receiving, via the web application, login credentials of a user,wherein the login credentials comprise a username and a password;verifying the login credentials as corresponding to an authorized user,wherein verifying the login credentials comprises transmitting the logincredentials to an identity catalog, and receiving authorized userinformation from the identity catalog; transmitting a first code to averified device associated with the authorized user; receiving a secondcode, via the web application, from the mobile device; verifying thesecond code by comparing the second code to the first code; based onverifying the second code, issuing an access card to the user of themobile device, wherein the access card includes access card information,the access card information is printed on the access card, and theaccess card provides access to a facility to the user of the mobiledevice.
 44. The method of claim 43, wherein transmitting the first codeto the verified device is performed by transmitting the first code tothe verified device via a mail server.
 45. The method of claim 43,further comprising recording one or more of a time stamp or the logincredentials in response to receiving, via the web application, the logincredentials.
 46. The method of claim 43, wherein issuing an access cardto the user of the mobile device is performed via a printer, wherein theprinter is located on the premises of the facility.
 47. An access cardissuance system comprising: a web server; an access card issuancedevice; an identity catalog; and a mail server; wherein the access cardissuance system is configured to: provide, via the web server, a webapplication to a mobile device associated with a user; receive, via theweb application, login credentials of the user; verify the logincredentials as corresponding to an authorized user, wherein verifyingthe login credentials is performed by matching, via the identitycatalog, the login credentials with login credentials of the authorizeduser; transmit, via the mail server, a code to a verified device,wherein contact information of the verified device is determined basedon information of the authorized user; receive, via the web application,the code from the mobile device; based on verifying the code receivedfrom the mobile device corresponds to the code transmitted to theverified device, instruct the access card issuance device to print anaccess card, wherein the access card includes access card informationproviding access rights to a facility, and the access card informationis printed on the access card, wherein the access card issuance deviceis located on the premises of the facility.